	\section{Overview}
		For our calendar system we have decided to use the Model/View/Controller (MVC) architectural style, where subsystems are classified and separated into three different areas and types: Model, View and Controller subsystems. The Model subsystems are used to maintain the domain knowledge, the View subsystems are for displaying the domain knowledge to the user, and the Controller subsystems manage the sequence of interactions with the user. \\
		
		The Model subsystem should not depend on any View or Controller subsystem. Changes in the states of the Model subsystem are notified to the View subsystems by a subscription or notify protocol, implemented with an Observer design pattern.\\
		\begin{figure}[!ht]
		\includegraphics{img/MVC.png}
		\caption{MVC pattern}
		\end{figure}
		
		The benefits of the architectural style are many: Firstly, the Observer design pattern allows the Model and View objects to be further decoupled by removing direct independencies from the model to the view subsystems. This, and the general separation of the subsystems, is also convenient since the user interfaces, i.e. the View and Controller subsystems, are subject to much more often change than the domain knowledge, i.e. the Model subsystem. This separation also makes the system much more modifiable. Furthermore, by removing the dependency between the View and Model subsystems, changes in the views, or user interfaces, do not have any effect on the domain knowledge (the Model subsystem).\\
		
		Secondly, the MVC is well suited for systems with multiple views for the same model, which in our case is needed – we have several Views but only need one Model subsystem to keep track of the domain knowledge. \\
		
		The main disadvantage, in our case, of the MVC architecture is that changes in the Model subsystem will mean changes in both the View and Controller subsystems, and this can quickly have effects on the performance. \\
		
		Our design pattern includes using a Proxy pattern to authorize changes submitted by users, \textbf{Bridge} and \textbf{Abstract Factory} pattern to support different kinds of storage, \textbf{Adapter} and \textbf{Command} pattern to support entries from Google Calendars, a \textbf{Strategy} pattern to support operations online and offline, and a \textbf{Composite} pattern when creating appointments, to support linked appointments.\\